1. Field of the Invention
The present invention relates generally to windows based computing programs and more particularly to a mouse driven splitter window layout.
2. The Prior Art
Modern computer systems interact with the user through a graphical user interface (GUI). The fundamental concept of a GUI is that of a window. A word processing program, for example, will display each document in its own separate window. Similarly, accounting and financing programs often display graphical or tabular representations of data in windows. Each window can be independently resized, repositioned, hidden or closed.
Sometimes it is desirable to display two or more documents, charts or table in one and the same window. Some word processing programs, for example, allow the user to partition a window horizontally into two areas, as shown in FIG. 1. Both areas will then display the window's current document. The two displays 10 and 20 can be scrolled independently, making it possible for the user to view different parts of the document simultaneously.
A window that is divided into two or more displays is called a splitter window. The independent areas of display inside the splitter window are called panes, and the separating bar between them is called a splitter, or splitter bar 30. Splitter bars can be moved horizontally or vertically with the mouse, thus changing the relative size of the panes.
Viewing different parts of a document could of course also be accomplished by opening a second window for the same document. However, the user would then have to go through the motions of positioning the two windows in such a way that they appear next to each other. Furthermore, resizing or repositioning one of the two windows would destroy this arrangement. Using a splitter window has the advantage of keeping the two displays in the same relative position no matter what happens to the entire window.
Another, perhaps even more important application of splitter windows occurs in accounting and finance programs. Here, it is often important to display two or more charts or tables next to each other. A good example would be a chart that displays the performance of several mutual funds over time. In order to evaluate this information, one would want another chart or table nearby that shows the risk characteristics of each mutual fund. Again, it would be possible to use two different windows in such a case. However, to make it easy for the user to always see the two displays simultaneously, it is much better to show them in different panes within a splitter window.
From a programmer's point of view, splitter windows do not per se pose any significant problems. Some development environments offer built-in support for splitter windows. The programmer can then create a splitter window with any given number of horizontal and vertical splitter bars by making a few simple function calls. If splitter windows are not supported by the development environment, it is a non-trivial but essentially routine exercise in GUI programming to implement them.
Using standard support for splitter windows, one can run horizontal splitter bars all the way across the window and vertical splitter bars all the way from the top to the bottom of the window. For maximal flexibility in the design of the user interface, it should also be possible to have nested splitter windows 200 as shown in FIG. 2. Here the main window is divided into six panes, using one horizontal and two vertical splitter bars. The top left pane is itself a splitter window made up of four panes, and the bottom right pane of these is again a nested splitter window made up of two panes side by side. Again, nested splitter windows may or may not be directly supported by the development environment. If they are not, implementing them is a non-trivial but essentially routine task.
Programs that use splitter windows face a particular user interface design problem. Namely, how should the user choose between different possible layouts of panes? With respect to the aforementioned prior art word processing programs, the answer is easy. There are only two possible layouts, namely, a plain window or a splitter window with two vertically stacked panes. The user chooses between the two simply by checking or unchecking a menu item.
For a program that displays various kinds of charts in splitter windows, the problem gets considerably more complicated. Here, it must be decided how the panes should be layed out, and it must be decided which chart should be shown in what pane. Older versions of Zephyr Associates' “StyleAdvisor” use a simple but limiting approach. There is a finite number of possible layouts, and the user selects one of these by checking or unchecking several menu items such as “Tables Only,” or “Show Performance Graph.”
Another approach would be to walk the user through a series of questions such as “How many vertically stacked panes would you like?” and “How many horizontally stacked panes would you like?” These questions would then have to be repeated for each pane to determine the subdivisions of nested splitter windows. After that, the user would still have to decide which chart to show in what pane.
While the first approach of having a finite number of layouts obviously places an undue limitation on the program's functionality, the second one of verbally interacting with the user is severely lacking in user-friendliness.